home *** CD-ROM | disk | FTP | other *** search
- FixP5Scsi
- _____________________________________________________________________________
-
- Some P5 SCSI devices drivers accesses chip memory for a controlled busy-wait
- loop. I don't know precisely what this busy-wait is used for, but the device
- does this by accessing the chip memory location 0xffff0 like this,
-
- nop
- tst.w $ffff0
- nop
-
- however, WITHOUT EVEN ALLOCATING THIS LOCATION BEFORE. Obviously, this makes
- MuGuardianAngle SCREAM, and for good reason: What you see here is very bad
- programming style and very questionable for a commercial product. First of
- all, the chip memory timing depends on the DMA traffic of the native hardware
- and hence on the screen solution. Second, even IF this busy wait has to made,
- it is required to ALLOCATE the memory location used for the dummy read.
-
- Unlike FixCybAccess, FixP5Scsi patches this problem by patching the code
- of the device drivers just in place, and avoids this hit. I haven't seen
- any problem by just removing this dummy wait here.
-
- Currently, the following device drivers are patched:
-
- 2060scsi.device
- 2040scsi.device
- cybscsi.device
- z3scsi.device
- 1240scsi.device
- 1260scsi.device
-
- In case you own a P5 SCSI board that shows similar symptons as mentioned
- above (namely, dummy reads from 0xffff0) and that is not on the list, please
- let me know.
-
-
- This fix *DOES NOT* fix the general DMA related problems of the cybscsi.device, as
- for example not calling the Os functions CachePreDMA() and CachePostDMA() and hence
- passing a (possibly invalid) logical address to the DMA logic instead of
- the true physical address.
-
- You only need to run this program if you want to use the MuGuardianAngel. To
- install it, type
-
- FixP5Scsi
-
- on the shell. It will patch the problem right away in the device driver
- and need not to be run to be permanently active.
-